1.11. Медиа

ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ

Всем

Медиа

Скорее всего, каждый пользователь ПК так или иначе использовал приложения для открытия медиа - смотрел видеофайлы или воспроизводил аудио. Допустим, музыку, или фильмы. Хотя в эпоху стриминговых сервисов, возможно, кто-то и не пробовал?

Давайте разбираться.

1. Медиа как тип данных и как предмет обработки

Под медиа в контексте вычислительных систем понимают данные, предназначенные для восприятия человеком через органы чувств, преимущественно зрение и слух. К этому классу относятся аудиоданные (речь, музыка), видеоданные (анимация, кино, видеозвонки), а также их комбинации — аудиовизуальные потоки. С точки зрения информатики медиа — это цифровые сигналы, прошедшие дискретизацию, квантование и кодирование. Именно этот фундаментальный факт определяет всю архитектуру программного обеспечения, работающего с медиа: оно не «воспроизводит картинку или звук», а декодирует, интерпретирует и синхронизирует потоки битов, преобразуя их в управляющие сигналы для аппаратных устройств вывода — динамиков, экранов, видеопроцессоров.

Таким образом, медиасофт — это набор «кнопок» (▶, ⏸, 🔊), идущий в комплекте со сложной системой компонентов, включая:

модули разбора контейнеров (container parsers),
демультиплексоры (demuxers),
декодеры (codecs, decoders),
модули временной синхронизации (clocks, PTS/DTS),
рендереры (audio renderers, video renderers),
интерфейс управления (UI/CLI),
сетевые абстракции (для стриминга),
и, при необходимости, модули постобработки (фильтры, эквалайзеры, эффекты).

Эта многоуровневая структура позволяет разделить задачи: одна часть софта отвечает за понимание формата, другая — за восстановление сигнала, третья — за его доставку в нужный момент на нужное устройство. Такой подход обеспечивает масштабируемость, переносимость и расширяемость.

2. Классификация медиасофта

Для целей систематизации удобно выделить два принципиальных типа медиасистем:

2.1. Локальные (оффлайн) медиаплееры

Это прикладные программы, устанавливаемые на устройство и работающие преимущественно с локально хранящимися файлами либо с сетевыми потоками, полностью контролируемыми пользователем (например, HTTP-поток по ссылке, RTSP-сервер в локальной сети). Их ключевые признаки:

Полный контроль над данными: пользователь выбирает, какой файл открыть, откуда загрузить, как долго хранить.
Отсутствие обязательной привязки к аккаунту: можно работать анонимно.
Зависимость от локального железа: декодирование может выполняться CPU (software decoding) или GPU (hardware-accelerated decoding, например, через VA-API, DirectX Video Acceleration, VideoToolbox).
Модульность: многие плееры поддерживают подключение внешних кодеков/фильтров (DirectShow filters в Windows, VST/LADSPA в аудио).
Независимость от сетевой доступности: после загрузки файла воспроизведение не требует интернета.

Примеры: VLC, MPC-HC, AIMP, foobar2000, SMPlayer.

2.2. Облачные стриминг-платформы (streaming services)

Это клиент-серверные системы, в которых медиаконтент хранится централизованно и доставляется по запросу через интернет. Клиентское приложение (native app, веб-интерфейс) выступает скорее терминалом ввода/вывода, чем полноценным медиаплеером. Его функции:

Авторизация и управление подпиской.
Запрос метаданных (каталоги, рейтинги, рекомендации).
Запрос и буферизация медиапотоков (обычно в зашифрованном виде, с DRM).
Воспроизведение только тех фрагментов, которые разрешены сервером.

Важно: такие сервисы, как Spotify, Яндекс.Музыка, YouTube Music, Apple Music, не являются медиаплеерами в классическом смысле. Это платформы доставки медиаконтента. Даже если клиент позволяет загрузить «офлайн-копию», она часто зашифрована и привязана к аккаунту, а прямое управление потоком (перемотка за пределы, анализ кодека, настройка буфера) ограничено или недоступно.

Терминологическая оговорка: слово «плеер» в названии сервиса (например, YouTube Player) часто используется как маркетинговый приём, но технически — это компонент внутри веб-приложения, реализующий функции воспроизведения в рамках строгой политики сервера. Он не эквивалентен VLC.

3. Архитектура локального медиаплеера

Рассмотрим типовую внутреннюю организацию современного медиаплеера на примере VLC Media Player, как наиболее полной и документированной реализации (libVLC — библиотека, лежащая в основе VLC, открыта и используется в тысячах проектов).

3.1. Стадия 1: Загрузка и парсинг контейнера

Файл (например, .mp4, .mkv, .avi) — это не «видео», а контейнер (container): структура данных, объединяющая один или несколько медиапотоков (аудио, видео, субтитры), метаданные (автор, длительность, обложка), таблицы индексов и служебную информацию. Задача модуля access/demux:

Определить тип контейнера (по сигнатуре, расширению, MIME-типу).
Распарсить его структуру (например, atoms в MP4, EBML в Matroska).
Извлечь отдельные элементарные потоки (elementary streams).
Выделить временные метки (Presentation Timestamp — PTS, Decoding Timestamp — DTS).
Передать потоки и метки в следующий модуль.

⚠️ Уязвимость: неправильный парсинг контейнера — частая причина CVE в медиасофт (переполнения буферов, use-after-free). Поэтому большинство плееров используют изолированные модули (sandboxing) или валидируют вход.

3.2. Стадия 2: Демультиплексирование и декодирование

Потоки направляются в соответствующие декодеры:

Для видео: H.264, VP9, AV1, HEVC и др.
Для аудио: AAC, MP3, FLAC, Opus, Vorbis и др.

Каждый декодер — это реализация стандарта, часто в виде внешней библиотеки (libavcodec из FFmpeg, OpenH264 от Cisco, dav1d для AV1). VLC динамически загружает нужный декодер на основе сигнатуры битстрима.

Декодирование может быть:

Программным (на CPU): медленнее, но универсальнее.
Аппаратным (на GPU/NPU): быстрее, но зависит от драйверов и поддержки (VDPAU, VAAPI, DXVA2, VideoToolbox, MediaCodec). VLC автоматически выбирает, если доступно.

Например: файл AV1 в MKV → контейнер распознаётся как Matroska → видео-поток идентифицирован как AV1 → плеер загружает dav1d → передаёт битстрим → dav1d выдаёт RAW-кадры в формате YUV 4:2:0.

3.3. Стадия 3: Постобработка и рендеринг

После декодирования данные часто проходят дополнительные преобразования:

Аудио: преобразование частоты дискретизации (resampling), нормализация громкости, эквалайзинг (FIR/IIR-фильтры), пространственное позиционирование (Dolby Atmos emulation).
Видео: масштабирование, деинтерлейсинг, коррекция цвета (HDR → SDR tone mapping), антиалиасинг.

Затем происходит рендеринг:

Аудио → отправляется в API вывода: ALSA/PulseAudio (Linux), Core Audio (macOS), WASAPI (Windows).
Видео → передаётся в видеодрайвер через OpenGL/Vulkan/Direct3D — либо как текстура (GPU rendering), либо как битмап (CPU rendering, медленнее).

Ключевой элемент — системные часы (system clock). Все потоки синхронизируются относительно единого временного источника (часто — аудио, как более тактильно чувствительный). Если видео отстаёт — кадры пропускаются (frame dropping); если опережает — вставляются задержки (frame waiting). Это и есть «плавное воспроизведение».

3.4. Стадия 4: Интерфейс и управление

UI (графический или консольный) не участвует в обработке медиа напрямую. Он:

Отправляет команды в ядро (play, pause, seek).
Запрашивает статус (position, buffering %).
Отображает метаданные (ID3-теги, обложки).

В VLC это реализовано через модель событий и асинхронные callback'и — чтобы UI не блокировался при длительных операциях (например, открытии сетевого потока).

4. Как получить и использовать локальный медиаплеер

4.1. Установка

Большинство плееров распространяются бесплатно и без рекламы (особенно open-source):

VLC:
- Windows/macOS: скачать .exe/.dmg с videolan.org.
- Linux: sudo apt install vlc (Debian/Ubuntu), sudo pacman -S vlc (Arch).
- Android/iOS: через Google Play / App Store.
✅ Проверка: после установки запустите, откройте Медиа → Открыть файл — выберите любой .mp3 или .mp4.
AIMP:
- Только Windows/Android: aimp.ru. Установщик не требует .NET или VC++ Redistributable.
✅ Особенность: при первом запуске предлагает импортировать медиатеку из других плееров.
MPC-HC (Media Player Classic — Home Cinema):
- Лёгкий, без зависимостей. Только Windows. Активно развивается сообществом: github.com/clsid2/mpc-hc.
❗ Важно: оригинальный MPC устарел; используйте именно HC или BE (Black Edition).

4.2. Запуск и базовое использование

Открытие файла:
- Через меню Файл → Открыть (или Ctrl+O).
- Перетаскиванием файла в окно плеера.
- Ассоциация расширений: клик правой кнопкой → Открыть с помощью... → выбрать плеер → Использовать по умолчанию.
Управление воспроизведением:
- ▶ / ⏸ — старт/пауза (Space).
- ← / → — перемотка на 5 сек (←) / 30 сек (Shift+←).
- Колесо мыши — громкость (Ctrl+колесо).
- Двойной клик — полноэкранный режим (F).
Настройка под себя:
- Инструменты → Настройки (VLC) / Меню → Настройки (AIMP).
- Здесь можно:
  - Выбрать выходное аудиоустройство (полезно при нескольких колонках/наушниках).
  - Включить аппаратное ускорение (рекомендуется для 4K/HEVC).
  - Настроить субтитры: кодировку, размер, синхронизацию (J/K для сдвига во времени).
  - Добавить горячие клавиши (например, Q — открыть эквалайзер в AIMP).

4.3. Работа с «проблемными» файлами

Если видео «тормозит»:
— Включите Аппаратное декодирование (в VLC: Инструменты → Настройки → Ввод/кодеки → Аппаратное ускорение декодирования).
— Попробуйте Пропускать кадры при перегрузке (VLC: Видео → Пропускать кадры).
Если звук есть, а видео — чёрный экран:
— Смените видеовывод: VLC → Инструменты → Настройки → Видео → Вывод → попробуйте OpenGL, Direct3D11, Automatic.
Если не читаются теги (исполнитель, альбом):
— В AIMP: клик правой кнопкой → Свойства → вкладка Теги → редактируйте вручную или загрузите из интернета (через MusicBrainz).
— В VLC: Инструменты → Медиаинформация (Ctrl+I).

5. Платформенная специфика

Платформа	Системные ограничения	Рекомендуемые решения
Windows	Поддержка DirectShow, WASAPI, DirectX. Много legacy-кодеков (встроенные в систему).	VLC (универсален), MPC-HC (лёгкий), AIMP (аудио). Избегайте «установщиков с ярлыками» — только официальные сайты.
macOS	Закрытая экосистема: VideoToolbox, Core Audio, ограничения на фоновые процессы. QuickTime — вшит в систему, но ограничен.	VLC (полная замена QuickTime), IINA (нативный интерфейс, основан на mpv), Elmedia Player (для AirPlay).
Linux	Высокая модульность: PulseAudio/ALSA, VAAPI/VDPAU, Wayland/X11. Нет стандартных кодеков из коробки (патенты).	VLC, MPV (минималистичный, CLI-ориентированный), Parole (для XFCE). Установите `ubuntu-restricted-extras` для MP3/H.264.
Android	Ограничение на фоновую активность, зависимость от MediaCodec API. Мало места для ручных настроек.	VLC, MX Player (поддержка внешних кодеков), n7player (для аудиофилов).
iOS	Строгий sandboxing, только через AVFoundation. Запрет на фоновое декодирование без подписки.	VLC (App Store), Infuse (для локальных файлов и NAS), Plex (для домашнего медиасервера).

💡 Замечание: iTunes — исторический продукт Apple. С 2019 г. в macOS Catalina он разделён на три приложения: Музыка, ТВ и Podcasts. На Windows iTunes всё ещё актуален для синхронизации iPhone, но как плеер почти не используется.

6. Безопасность и этика использования медиасофта

Открытый исходный код (VLC, MPV, AIMP) позволяет независимую проверку на бэкдоры. Закрытые плееры (некоторые «ускорители видео» в App Store) могут собирать метаданные файлов.
Не устанавливайте кодек-паки (K-Lite, CCCP) «для совместимости» — современные плееры (VLC, MPV) включают всё необходимое. Сторонние кодеки — частый вектор атак.
Сетевые потоки (RTSP, HLS, YouTube-ссылки) могут инициировать подключения к сторонним серверам. Проверяйте URL и используйте файрвол.

Часть 2. Форматы, кодеки и структура медиаданных

1. Контейнер — не «упаковка», а оркестровщик

Распространённое заблуждение: «MP4 — это видеоформат». Нет. MP4 (MPEG-4 Part 14) — это контейнерный формат, стандарт ISO/IEC 14496-14. Он не определяет, как кодируется видео или аудио, а лишь как их объединить, снабдить метаданными и обеспечить синхронизацию.

📌 Аналогия: контейнер — как DVD-диск. На нём может быть фильм в MPEG-2, с субтитрами в VobSub, меню на DVD-Video. Или — документ в PDF, с вложениями. Или — архив .zip. Суть не в содержимом, а в структуре хранения.

1.1. Почему контейнеры необходимы?

Без контейнера пришлось бы хранить:

Видеопоток — отдельным файлом (.h264).
Аудиопоток — отдельно (.aac).
Субтитры — третьим файлом (.srt).
Метаданные — четвёртым (.txt).

И пользователь должен был бы вручную синхронизировать начало воспроизведения всех четырёх. Контейнер решает это, предоставляя:

Мультиплексирование — объединение потоков в один байтовый поток.
Индексирование — таблицы, позволяющие быстро перематывать (seek) без перебора всего файла.
Метаданные — заголовки, теги, DRM-информация.
Синхронизацию по времени — PTS/DTS (Presentation/Decoding Timestamps).

1.2. Сравнение популярных контейнеров

Контейнер	Основа	Плюсы	Минусы	Где используется
MP4	ISO Base Media File Format (на базе QuickTime)	Широкая поддержка, эффективные индексы, поддержка фрагментации (для стриминга), встроенная DRM (CENC)	Сложная структура, не все расширения одинаково совместимы	YouTube, мобильные устройства, Apple ecosystem
Matroska (.mkv)	EBML (Extensible Binary Meta Language) — двоичный XML	Гибкость: можно вложить всё: видео, аудио, субтитры (встроенные), главы, 3D-стерео, метаданные на любом языке	Менее эффективен для быстрого seek'а в длинных файлах; не поддерживается «из коробки» в iOS/Safari	Архивные копии, рипы, домашние медиатеки
AVI	RIFF (Resource Interchange File Format) — Microsoft, 1992 г.	Простота, почти полная поддержка в Windows	Нет встроенной поддержки переменной частоты кадров (VFR), слабые метаданные, не поддерживает современные кодеки «напрямую»	Legacy-видео, оцифровка старых записей
MOV	QuickTime File Format — Apple, 1990-е	Глубокая интеграция с macOS, поддержка сложных временных шкал (timecode), метаданные для постпродакшена	Закрытая спецификация (частично), большие накладные расходы	Профессиональный видеомонтаж (Final Cut, Premiere)
WebM	Подмножество Matroska	Оптимизирован под VP9/AV1 + Opus, открытый, без патентов	Ограниченная поддержка аудио (нет MP3), нет DRM	Веб-видео (HTML5 `<video>`), Discord, WhatsApp

💡 Практический вывод:

Хотите максимальную совместимость с телефонами и YouTube? → MP4 + H.264 + AAC.

Архивируете фильм с несколькими дорожками и субтитрами? → MKV.

Работаете в Final Cut? → MOV/ProRes.

Публикуете на сайт? → WebM + MP4 fallback.

2. Кодеки

Кодек (от coder-decoder или compressor-decompressor) — алгоритм преобразования сырого (RAW) медиасигнала в сжатый битстрим и обратно. Ключевое: сжатие почти всегда — с потерями (lossy), за исключением профессиональной аудиозаписи (FLAC, ALAC) или медицинской визуализации.

2.1. Аудиокодеки

Исходный аналоговый сигнал оцифровывается по теореме Котельникова–Шеннона:
Частота дискретизации ≥ 2 × максимальной частоты в сигнале.
Для человеческого слуха (20 Гц–20 кГц) → 44.1 кГц (CD) или 48 кГц (видео).

Затем применяется квантование: амплитуда округляется до ближайшего уровня. 16 бит → 65 536 уровней → динамический диапазон ~96 дБ.

Но 16 бит × 44.1 кГц × 2 канала = 1.4 Мбит/с на стерео. Для стриминга — слишком много. Отсюда — психоакустическое моделирование.

Принципы lossy-аудиокодеков:

Маскирование по частоте: громкий тон «заглушает» тихие соседние частоты → их можно отбросить.
Маскирование по времени: всплеск громкости скрывает тихие звуки до и после него.
Стерео-моделирование: L+R и L−R вместо двух независимых каналов.

Кодек	Год	Битрейт (стерео)	Особенности
MP3 (MPEG-1 Layer III)	1993	128–320 кбит/с	Первый массовый формат. Поддержка повсеместна. Качество на 128 кбит/с — приемлемое, но артефакты («звон» в высоких частотах).
AAC (Advanced Audio Coding)	1997	96–256 кбит/с	Стандарт для MP4, iTunes, YouTube. Лучше MP3 при том же битрейте. Поддержка HE-AAC (для низких скоростей — 48 кбит/с).
Opus	2012	6–510 кбит/с	Открытый, без патентов. Оптимизирован под любые задачи: VoIP (6 кбит/с), музыка (128+), low-latency. Используется в WhatsApp, Discord, WebRTC.
FLAC	2001	~50–70% от WAV	Lossless. Восстанавливает точную копию. Используется в архивах, Hi-Res аудио.
Vorbis	2000	80–500 кбит/с	Открытая альтернатива MP3/AAC. Используется в WebM, Ogg. Качество выше MP3, но сложнее в декодировании.

🎧 Эксперимент для понимания:
Возьмите один и тот же трек в MP3 (128 кбит/с), AAC (128), Opus (128). Прослушайте в наушниках. Обратите внимание на:

«Размытость» высоких частот (цимбалы, шипение «s»).

Пропадание тихих инструментов в паузах.
Это — следы психоакустической модели.

2.2. Видеокодеки

Видео — это последовательность кадров. RAW-видео в Full HD (1920×1080, 24 бит, 30 кадр/с):
1920 × 1080 × 3 байта × 30 = 178 МБ/с → 640 ГБ/час. Неприемлемо.

Сжатие использует два типа избыточности:

Пространственная: соседние пиксели похожи (например, небо).
Временная: соседние кадры почти идентичны (фон не меняется).

Эволюция видеокодеков:

Кодек	Год	Ключевые идеи	Битрейт (1080p30)	Статус
MPEG-2	1995	I/P/B-кадры, DCT, квантование	8–12 Мбит/с	DVD, цифровое ТВ. Устарел.
H.264 / AVC	2003	CABAC (контекстно-адаптивное кодирование), более точное предсказание движения, deblocking filter	4–8 Мбит/с	Де-факто стандарт. Поддержка везде. Патенты до 2028 г.
VP9	2013	От Google. Аналог H.265, но без патентов. Поддержка 10/12 бит, HDR.	2.5–5 Мбит/с	YouTube (с 2014), WebM.
H.265 / HEVC	2013	В 2 раза эффективнее H.264. Большие CU (Coding Units), SAO (Sample Adaptive Offset).	2–4 Мбит/с	4K-видео, Blu-ray. Сложные патентные лицензии.
AV1	2018	От AOMedia (Google, Netflix, Amazon). Открытый. Superblocks, warped motion, CDEF filter.	1.5–3 Мбит/с	YouTube, Netflix, Discord. Декодирование требует GPU.
VVC (H.266)	2020	+50% эффективности к AV1. Но сложность кодирования ×10.	1–2 Мбит/с	Пока — исследовательский.

🔍 Как работает I/P/B-структура (на примере H.264):

I-кадр (Intra): сжимается внутри себя, как JPEG. Точка входа для декодера.

P-кадр (Predicted): кодируется как разница от предыдущего I/P-кадра + вектор движения.

B-кадр (Bidirectional): предсказывается от прошлого и будущего кадров → выше сжатие, но требует буферизации.

Поток: I → P → B → B → P → B → I…
При перемотке плеер ищет ближайший I-кадр — отсюда «скачки» при seek'е.

3. Метаданные: невидимый слой информации

Метаданные — данные о данных. В медиа они бывают:

3.1. Уровень контейнера (global metadata)

Длительность, битрейт, размер.
DRM-информация (например, pssh box в MP4 для Widevine).
Главы (chapter markers) — как «закладки» в аудиокниге.

3.2. Уровень потока (stream-level metadata)

Видео: разрешение, частота кадров, профиль кодека (Baseline/Main/High).
Аудио: количество каналов, частота дискретизации, language tag.

3.3. Уровень прикладной семантики (user-facing metadata)

ID3v2 (для MP3): исполнитель, альбом, обложка (APIC frame), текст песни.
Vorbis Comments (для Ogg/FLAC): гибкие пары ключ=значение (например, REPLAYGAIN_TRACK_GAIN=-3.2).
Exif (в MOV/MP4): данные GPS, модель камеры, время съёмки.

📂 Как посмотреть метаданные:

VLC: Инструменты → Медиаинформация → Кодеки (технические) + Метаданные (пользовательские).

exiftool имя_файла.mp4 — в командной строке (универсально).

AIMP: клик ПКМ по треку → Свойства → вкладка Теги.

⚠️ Приватность: метаданные могут содержать:

Имя компьютера (в некоторых MP4, снятых смартфонами).
Геолокацию (если включена в камере).
Серийный номер устройства.
Перед публикацией — очищайте через exiftool -all= файл.mp4.

4. Потоковое вещание

Локальный плеер и стриминг-сервис используют одни и те же кодеки, но логика доставки принципиально иная.

4.1. HTTP Live Streaming (HLS) — Apple, но де-факто стандарт

Суть: видео разбивается на фрагменты (chunks) по 2–10 секунд (.ts или .mp4), а клиент последовательно их запрашивает по HTTP.

Структура:

playlist.m3u8
├── segment_0001.ts
├── segment_0002.ts
├── segment_0003.ts
└── ...

playlist.m3u8 — текстовый файл (формат M3U):

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXTINF:9.009,
segment_0001.ts
#EXTINF:9.009,
segment_0002.ts
#EXT-X-ENDLIST

Преимущества:

Работает через любой веб-сервер (Nginx, Apache).
Поддержка адаптивного битрейта: несколько m3u8 с разным качеством (video_360p.m3u8, video_1080p.m3u8), клиент сам выбирает по скорости сети.
Лёгкое кэширование CDN.

4.2. MPEG-DASH (Dynamic Adaptive Streaming over HTTP)

Аналог HLS, но открытый стандарт (ISO/IEC 23009-1). Вместо .m3u8 — XML-манифест (manifest.mpd), фрагменты — в формате CMAF (Common Media Application Format, на базе MP4).

Плюсы DASH:

Единый фрагмент для нескольких браузеров (в HLS Apple требует .ts, остальные — .mp4).
Более гибкое управление буфером.
Поддержка DRM через CENC (Common Encryption).

YouTube, Netflix, Twitch — используют комбинацию HLS и DASH в зависимости от устройства.

4.3. RTMP, SRT, WebRTC — для интерактивного стриминга

RTMP (Real-Time Messaging Protocol) — Adobe, 2002. Низкая задержка (~1–3 с), но требует специального сервера (Nginx-rtmp, Wowza). Умирает из-за отсутствия поддержки в браузерах (без Flash).
SRT (Secure Reliable Transport) — Haivision. Открытый, с коррекцией потерь, шифрованием. Используется в профессиональном вещании (например, OBS → сервер).
WebRTC — для видеочатов. Задержка <500 мс. Используется в Zoom, Jitsi, Discord.

5. Почему «купленный фильм» нельзя сохранить

DRM (Digital Rights Management) — технология ограничения использования контента. В медиа она реализована через:

Шифрование видеопотока (обычно AES-128 в режиме CBC или CTR).
Лицензионный сервер, выдающий ключ только авторизованным клиентам.
Secure Environment на устройстве:
- Widevine (Google) → Trusted Execution Environment (TEE) в Android.
- FairPlay (Apple) → Secure Enclave в iPhone/Mac.
- PlayReady (Microsoft) → Protected Media Path (PMP) в Windows.

🔐 Как это выглядит в VLC?
Попытка открыть зашифрованный MP4 (например, с Netflix) → «Неподдерживаемый формат», даже если кодек известен. Потому что без лицензии — битстрим — просто шум.

Этическая дилемма: DRM защищает права правообладателя, но:

Ломает совместимость (файл работает только в одном приложении).
Усложняет архивирование (культурное наследие).
Не предотвращает пиратство (запись с экрана — Screen Capture).

6. Практическое руководство: как создать медиафайл

Для полноты картины — как из «ничего» получить .mp4, который откроется в любом плеере.

Инструменты:

FFmpeg — универсальный конвертер (open-source, CLI).
HandBrake — GUI-обёртка над FFmpeg (для новичков).
OBS Studio — для записи/стриминга.

Пример: конвертация в совместимый MP4

ffmpeg -i input.mkv \
  -c:v libx264 \
  -profile:v baseline \
  -level 3.0 \
  -pix_fmt yuv420p \
  -c:a aac \
  -b:a 128k \
  -movflags +faststart \
  output.mp4

Разбор ключевых опций:

-c:v libx264 — кодировать видео через H.264.
-profile:v baseline — максимальная совместимость (даже с 2010 Android).
-level 3.0 — ограничение на разрешение/битрейт (Baseline Level 3.0 = до 720p30).
-pix_fmt yuv420p — цветовое пространство, понятное всем плеерам (не 4:4:4!).
-movflags +faststart — переместить индекс в начало файла → мгновенный старт в браузере.

📌 Проверка: откройте output.mp4 в Safari (самый привередливый к MP4) — должно заиграть.

Часть 3. Аппаратное ускорение, цветовые модели и аудиоподсистемы

1. Аппаратное ускорение

Декодирование видео — одна из самых вычислительно ёмких задач на потребительских устройствах. Пример:

Формат	Разрешение	FPS	Примерная нагрузка на CPU
H.264	1080p	30	~10–15% одного ядра (Intel i5, 2020)
HEVC	4K	60	~70–90% четырёх ядер
AV1	4K	60	>100% восьми ядер (software decoding)

Поэтому все современные SoC (системы-на-кристалле) включают специализированные блоки:

1.1. Типы аппаратных декодеров/энкодеров

Блок	Производитель	Поддерживаемые кодеки	Интерфейс
Intel Quick Sync Video	Intel	H.264, HEVC (8/10 бит), VP9 (8/10), AV1 (decode only, 12-е поколение+)	VAAPI (Linux), Media SDK (Windows), VideoToolbox (macOS через Rosetta)
NVIDIA NVENC/NVDEC	NVIDIA	H.264, HEVC, AV1 (40-я серия+), VP9	NVDEC API, FFmpeg через `h264_cuvid`, `hevc_cuvid`
AMD VCE/VCN	AMD	H.264, HEVC, VP9, AV1 (RDNA3+)	VAAPI (Linux), AMF (Windows)
Apple Video Engine	Apple	H.264, HEVC, ProRes, AV1 (M2+)	VideoToolbox
MediaCodec	Qualcomm, Exynos, Kirin	H.264, HEVC, VP9, AV1 (Snapdragon 8 Gen 2+)	Android NDK / Java MediaCodec API

💡 Важно: поддержка на уровне чипа ≠ поддержка в ОС. Например, Intel 11-го поколения аппаратно декодирует AV1, но драйверы Linux добавили поддержку только в ядре 5.17+.

1.2. Как плеер использует ускорение

Рассмотрим сценарий: VLC воспроизводит 4K AV1 через VAAPI на Ubuntu.

Контейнерный парсер (libmp4) выделяет AV1-битстрим.
Демультиплексор передаёт его в vaapi_decoder.
VLC вызывает vaBeginPicture() → создаётся видеоконтекст в GPU.
Битстрим копируется в видеопамять через vaRenderPicture() (без CPU-обработки).
Декодер GPU (внутри iGPU) выполняет:
- Парсинг tile groups,
- Обратное преобразование (inverse transform),
- Фильтрация (CDEF, LR),
- Реконструкция кадра в YUV.
Готовый кадр остаётся в видеопамяти → VLC передаёт его напрямую в OpenGL/Vulkan рендерер через EGLImage или DMABUF.

Преимущества:

Нулевая загрузка CPU.
Отсутствие копирования между CPU/GPU (zero-copy path).
Поддержка HDR → GPU может сразу применить tone mapping.

1.3. Проверка и включение ускорения

VLC:
Инструменты → Настройки → Ввод/кодеки → Аппаратное ускорение декодирования → выбрать VA-API, VDPAU, D3D11, VideoToolbox.
В логе (Инструменты → Сообщения, уровень Отладка) — строки вида:
vaapi decoder: using surface format NV12
avcodec: using hardware decoding: av1 (vaapi)
FFmpeg:
```
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
       -i input.mkv -f null -
```
В выводе: [AVHWDeviceContext @ ...] Trying to use DRM render node
Если не поддерживается — ошибка: No decoder surfaces left.
Linux:
Убедитесь, что установлены пакеты:
intel-media-va-driver-non-free (для AV1),
libva-utils → команда vainfo покажет список поддерживаемых профилей.

⚠️ Ограничения:

Аппаратное декодирование не позволяет применять фильтры в FFmpeg (например, scale, hqdn3d).

Некоторые DRM-видео (Netflix в браузере) требуют только аппаратное декодирование — иначе «чёрный экран».

2. Цвет в цифровом видео

Цвет — не RGB. Это система координат, зависящая от:

Цветового пространства (gamut),
Функции передачи (transfer function),
Метода сэмплирования (chroma subsampling).

2.1. Цветовые пространства (gamut)

Стандарт	Год	Область охвата	Использование
Rec.601 (BT.601)	1982	SD (PAL/NTSC)	Старые DVD, аналоговое ТВ
Rec.709 (BT.709)	1990	HD (sRGB)	Full HD, Blu-ray, YouTube
DCI-P3	2005	~25% шире sRGB	Кинотеатры, Apple Display, OLED-телефоны
Rec.2020 (BT.2020)	2012	~75% видимого спектра (теоретически)	UHD Blu-ray, HDR-видео

📊 Пример: зелёный пиксель в Rec.709 = (0, 255, 0) в sRGB.
В Rec.2020 тот же код (0, 255, 0) — другой оттенок зелёного, более насыщенный.
Если не указать метаданные — плеер покажет «неправильный» цвет.

2.2. Функции передачи (transfer functions)

Как кодируются яркости:

Тип	Характеристика	Примеры
Gamma 2.2 / sRGB	Нелинейная, для SDR	Все старые видео
PQ (Perceptual Quantizer)	Логарифмическая, 0.0001–10 000 нит	HDR10, Dolby Vision
HLG (Hybrid Log-Gamma)	Смешанная: SDR + HDR в одном сигнале	Японское/британское эфирное ТВ

PQ сохраняет детали в тенях и в светах, но требует HDR-дисплея. На SDR-экране — «выцветшее» изображение без tone mapping.
HLG обратно совместим: SDR-телевизор игнорирует «верхний» слой → видит обычное изображение.

2.3. Сэмплирование цвета (chroma subsampling)

Человек хуже различает цвет, чем яркость → можно уменьшить разрешение цветовых компонентов.

Форматы:

YUV 4:4:4 — полное разрешение (яркость Y, цвет U и V — по 1 сэмплу на пиксель).
Используется в ProRes, несжатом видео.
YUV 4:2:2 — U и V — по 1 сэмплу на 2 пикселя по горизонтали.
Studio-стандарт (DNxHD, XDCAM).
YUV 4:2:0 — U и V — по 1 сэмплу на блок 2×2 пикселя.
Всё потребительское видео (H.264, HEVC, AV1).

🔍 Как проверить в VLC:
Инструменты → Медиаинформация → Кодеки → строка Chroma: I420 = 4:2:0, I444 = 4:4:4.

2.4. HDR: не «ярче», а «правильнее»

HDR — не про максимальную яркость, а про динамический диапазон: соотношение между самой тёмной и самой светлой деталью.

SDR (Rec.709): 100 нит (кандела/м²), 8 бит → 256 уровней яркости.
HDR10: 1000+ нит, 10 бит → 1024 уровня, метаданные SMPTE ST 2086 (Mastering Display Color Volume).
Dolby Vision: динамические метаданные (на каждый кадр), 12 бит.

Tone mapping — ключевой процесс при выводе HDR на SDR-устройство:

Плеер читает метаданные HDR (например, MaxCLL=1000, MaxFALL=200).
Применяет функцию (например, Reinhard, Hable) → сжимает диапазон 0–10000 нит до 0–100.
Корректирует цвета под gamut дисплея.

⚠️ Проблема: многие YouTube-видео в HDR — с неправильными метаданными. VLC (4.0+) и mpv имеют ручные настройки tone mapping (--hdr-compute-peak=yes, --target-prim=display).

3. Аудиоподсистемы ОС

Звук — последний этап в цепочке, где физика напрямую влияет на восприятие.

3.1. Путь аудиосигнала в ОС

Плеер → Аудиобуфер (PCM, float32) 
       → Микшер (PulseAudio/PipeWire/Core Audio) 
       → Драйвер (ALSA, snd_hda_intel) 
       → ЦАП (Цифро-Аналоговый Преобразователь) 
       → Усилитель → Динамик

Каждое звено вносит искажения:

Микшер — ресэмплинг (например, 44.1 кГц → 48 кГц), который может вызвать алиасинг без качественного фильтра.
Драйвер — буферизация (latency). snd_pcm_sw_params_set_avail_min() в ALSA задаёт порог срабатывания.
ЦАП — шум, нелинейность, джиттер.

3.2. Сравнение аудиосерверов

Сервер	ОС	Архитектура	Плюсы	Минусы
PulseAudio	Linux	Монолитный демон	Стабильность, поддержка Bluetooth A2DP	Высокая latency (~20–100 мс), устаревший протокол
PipeWire	Linux	Граф pipeline'ов (с нодами)	Единая система для аудио и видео (веб-камеры), низкая latency (1–5 мс), поддержка JACK	Молодой, возможны регрессии
Core Audio	macOS	Ядро + HAL (Hardware Abstraction Layer)	Низкая latency, zero-copy, поддержка многоканальности	Закрытый API
WASAPI	Windows	Режимы: Shared / Exclusive	В Exclusive Mode — прямой доступ к ЦАП	Требует администраторских прав для Exclusive

🔧 Как снизить latency в Linux:

# Для PipeWire:
echo 'default.clock.rate = 48000' >> ~/.config/pipewire/pipewire.conf
echo 'default.clock.allowed-rates = [ 48000 ]' >> ~/.config/pipewire/pipewire.conf
systemctl --user restart pipewire

3.3. Эквалайзеры

Эквалайзер — набор фильтров, каждый из которых усиливает/ослабляет узкий диапазон частот.

В AIMP используется параметрический эквалайзер на базе:

Биквадратных фильтров (biquad filters) — IIR, рекурсивные.
Каждый слот: частота, добротность (Q), усиление (dB).

Пример фильтра (низкочастотный):

H(z) = (b0 + b1·z⁻¹ + b2·z⁻²) / (1 + a1·z⁻¹ + a2·z⁻²)

Коэффициенты b0..a2 вычисляются по формулам RBJ (Robert Bristow-Johnson).

📉 Почему нельзя «поднять все ползунки на максимум»?

Суммарное усиление → clipping (перегрузка) → искажения.

Фазовые сдвиги между полосами → размывание стереообраза.

3.4. 3D-звук: от стерео до пространственного

Stereo (2.0) — два канала, панорамирование по закону косинуса.
Surround (5.1) — дискретные каналы (фронт/тыл/центр/LFE).
Ambisonics (B-Format) — запись поля давления (W, X, Y, Z), конвертируется под любую акустическую систему.
Dolby Atmos / DTS:X — объёмные объекты («звук вертолёта над головой»), передаются как метаданные.

Плееры поддерживают:

VLC: через модуль spatialaudio (Ambisonics → binaural для наушников).
Foobar2000: через плагин Dolby Access (требует лицензии).
AIMP: поддержка многоканальных WAV/MKV, но без объектного звука.

4. Тестирование и диагностика

4.1. Видео: проверка синхронизации и цвета

Lip sync test: видео с человеком, говорящим «паттерн-тест». Отставание >40 мс — заметно.
Color bars: SMPTE test pattern (75% bars). Проверка:
- Есть ли полоса чёрного (PLUGE).
- Верны ли оттенки серого (grayscale ramp).
- Синяя полоса → проверка цветности (в режиме Blue Only).
HDR test:
HDR10 Test Patterns (YouTube) — проверка peak brightness, colour volume.

4.2. Аудио: измерение latency и искажений

Round-trip latency:
Запишите микрофон + воспроизведение через петлю → задержка = разность пиков.
Инструмент: jack_delay (Linux), ASIO4ALL Latency Test (Windows).
THD+N (Total Harmonic Distortion + Noise):
Подайте 1 кГц синус → измерьте шум и гармоники. Хороший ЦАП: <0.01%.
Frequency response:
Воспроизведите sweep 20 Гц–20 кГц → запишите микрофоном → постройте АЧХ (Audacity → Plot Spectrum).

4.3. Инструменты

Задача	Инструмент
Анализ видео	`mediainfo`, `ffprobe`, Elecard StreamEye (профессиональный)
Анализ аудио	Audacity, REW (Room EQ Wizard), ARTA
Замер latency	`jack_iodelay`, LatencyMon (Windows)
Проверка HDR	CalMAN, Spears & Munsil HDR Benchmark

5. Исторический контекст

Год	Событие	Влияние
1977	PCM на CD (16 бит/44.1 кГц)	Стандарт качества на 30 лет
1992	MPEG-1 → MP3	Массовое распространение цифровой музыки
2003	H.264	Видео в интернете стало возможным
2008	PulseAudio в Ubuntu	Единая аудиосистема для Linux (со всеми проблемами)
2013	HEVC / VP9	4K-видео на потребительских устройствах
2015	Firefox поддерживает WebM+VP9	Конец эпохи Flash
2018	AV1 релиз	Первый открытый кодек, сравнимый с HEVC
2020	PipeWire по умолчанию в Fedora	Новая эра Linux-аудио
2023	Apple M2 поддерживает AV1 decode	Массовое внедрение AV1

Часть 4. Медиасерверы, стриминг и домашняя медиаинфраструктура

1. Что такое медиасервер? Не просто «папка с фильмами»

Медиасервер — это серверное приложение, обеспечивающее:

Индексацию медиафайлов (фильмы, сериалы, музыка),
Метаданные (названия, описания, обложки, рейтинги),
Транскодирование «на лету» для совместимости с клиентами,
Управление доступом (пользователи, роли, профили),
Синхронизацию состояния (просмотрено/не просмотрено, позиция воспроизведения).

Важно: медиасервер ≠ файловый сервер (Samba/NFS). Он работает на прикладном уровне, понимает структуру медиаконтента.

1.1. Три поколения медиасерверов

Поколение	Примеры	Архитектура	Ограничения
1. DLNA-серверы	MiniDLNA, PS3 Media Server	Файл → метаданные из ID3/EXIF → UPnP-описание → поток через HTTP	Нет пользователей, нет транскодирования «из коробки», слабые метаданные
2. Клиент-серверные системы	Plex (2008), Emby (2013)	Сервер (индексация + транскодирование) + клиенты (мобильные/Web/TV) + облачный аккаунт	Зависимость от облака (Plex), платные функции (Emby Premiere)
3. Открытые децентрализованные	Jellyfin (2018), Gerbera	Сервер + клиенты, без облачного аккаунта, API-first, плагины	Меньше поддержки устройств «из коробки», требуется настройка

📌 Ключевое различие:

Plex/Emby — платформа: сервер бесплатен, но функции (mobile sync, hardware transcoding) требуют подписки.

Jellyfin — инструмент: всё открыто, но интеграция с Apple TV/Chromecast — через пользовательские усилия.

1.2. Архитектура Jellyfin (как типового open-source сервера)

[Медиафайлы]  
     ↓  
[Jellyfin Server]  
├── Metadata Manager (TheMovieDB, MusicBrainz, TheTVDB)  
├── Library Scanner (фоновый индексатор)  
├── Transcoding Engine (FFmpeg + hardware acceleration)  
├── Live TV & DVR (через TVHeadend или HDHomeRun)  
├── API Layer (REST, WebSocket для событий)  
└── Plugin Manager (аналитика, аудиоанализ, syncplay)  
     ↓  
[Clients: Web, Android, iOS, Kodi, MPV, CLI]

Metadata Manager — не просто парсит имена файлов (Игра престолов S01E01.mkv), а:
— Запрашивает TheTVDB по хэшу файла,
— Скачивает обложки в 4K,
— Сопоставляет аудиодорожки с языками (по названию файла: rus.ac3, eng.aac).
Transcoding Engine — динамически решает:
— Если клиент поддерживает H.265 → отдаёт исходник (direct play).
— Если клиент — старый Android → транскодирует в H.264 + AAC через ffmpeg -c:v h264_nvenc -c:a aac.
— Если два пользователя смотрят одно видео → один транскод-процесс, multicast-поток.

⚙️ Пример FFmpeg-команды для прямого вещания в браузер (HLS):
ffmpeg -ss 3600 -i movie.mkv \
       -c:v libx264 -profile:v baseline -level 3.0 \
       -vf "scale=1280:720" \
       -c:a aac -b:a 128k \
       -f hls -hls_time 4 -hls_list_size 5 \
       /tmp/stream.m3u8
Сервер запускает эту команду только при первом запросе, кэширует сегменты, останавливает процесс при неактивности.

2. Протоколы локального стриминга

2.1. UPnP/DLNA — стандарт 2000-х, но всё ещё жив

UPnP (Universal Plug and Play) — обнаружение устройств в сети (SSDP: M-SEARCH * HTTP/1.1).
DLNA (Digital Living Network Alliance) — профиль UPnP для медиа:
— DMS (Digital Media Server) — отдаёт контент,
— DMR (Digital Media Renderer) — воспроизводит (TV, проектор),
— DMC (Digital Media Controller) — управляет (телефон).

📡 Как это работает:

Телефон (DMC) отправляет multicast-запрос: «Кто здесь DMR?»

Телевизор (DMR) отвечает: «Я — Samsung TV, поддерживаю H.264, AAC»

Телефон запрашивает у DMS (Jellyfin) список фильмов.

При выборе — DMC говорит DMR: «Воспроизведи http://jellyfin/video.mkv»

Телевизор напрямую тянет файл с сервера — телефон не участвует в потоке.

2.2. Chromecast / Google Cast

Google Cast — не DLNA. Это:

Sender App (на телефоне) → отправляет URL + метаданные на Chromecast.
Receiver App (на Chromecast) — лёгкое веб-приложение (HTML5 + cast.framework), которое: — Загружает https://jellyfin/video.mp4, — Воспроизводит через <video>, — Синхронизирует позицию по WebSocket.

Преимущества:

Низкое энергопотребление телефона (он только «пульт»),
Поддержка DRM (Widevine L1),
Возможность «кастить» веб-страницы (YouTube, Netflix).

2.3. AirPlay (Apple)

AirPlay 2 — проприетарный протокол поверх:

mDNS/DNS-SD — обнаружение (_airplay._tcp.local),
HTTP POST /play — управление,
NTP — синхронизация времени (для multi-room),
FairPlay Streaming — DRM.

Особенность: AirPlay может передавать не только медиа, но и:

Экран устройства (Screen Mirroring),
Аудио с микрофона (для видеозвонков),
Контроль громкости через AVB (Audio Video Bridging).

🔄 Сравнение latency:

DLNA: 1–3 сек (буферизация),

Chromecast: 0.5–1.5 сек,

AirPlay: 0.2–0.8 сек (благодаря NTP и low-latency кодекам).

3. Домашняя медиаинфраструктура

3.1. Выбор носителя: HDD vs SSD vs NVMe

Тип	Плюсы	Минусы	Для чего
HDD (8–20 ТБ)	Низкая цена/ГБ, высокая надёжность при архиве	Высокая latency (7–15 мс), шум, вибрация	Хранилище фильмов, архивы
SSD SATA	Тихий, низкое энергопотребление	Ограниченный TBW, дороже HDD	ОС + кэш метаданных
NVMe	Скорость `>`3 ГБ/с, latency `<`0.1 мс	Высокая цена, греется	Транскодирование «на лету», базы данных

💡 Практический совет:
— Системный диск — SSD (256 ГБ),
— Медиа — объёмные HDD в RAID-Z1 (ZFS),
— Кэш метаданных (L2ARC) — NVMe (если >100 ТБ данных).

3.2. Файловые системы для медиа

ФС	Поддержка	Особенности
ext4	Linux	Быстро, просто, но нет контроля целостности
Btrfs	Linux	Copy-on-Write, снапшоты, сжатие (`zstd`), но нестабильно при HDD-массивах
ZFS	Linux (через ZFS on Linux), FreeBSD	End-to-end checksumming, RAID-Z (аналог RAID-5 без write hole), deduplication, но требует RAM (1 ГБ на 1 ТБ данных)

✅ Почему ZFS — выбор для медиаархива:

При сбое диска в RAID-5 — возможна потеря всего массива из-за URE (Unrecoverable Read Error).

ZFS RAID-Z проверяет checksum при каждом чтении → обнаруживает «тихие» ошибки.

Снапшоты позволяют откатить удалённый фильм за 5 секунд.

3.3. Сборка медиасервера на Raspberry Pi 5 (практический гайд)

Цель: тихий, энергоэффективный сервер для 10 ТБ фильмов, с поддержкой direct play (без транскода).

Компоненты:

Raspberry Pi 5 (8 ГБ RAM, PCIe 2.0 x1)
M.2 SATA SSD (512 ГБ) — для ОС и кэша
USB 3.0 → SATA-адаптер (с отдельным питанием)
2× HDD 6 ТБ (WD Red Plus)

Шаги:

Установите Ubuntu Server 24.04 (64-bit).

Включите ZFS:

sudo apt install zfsutils-linux
sudo zpool create tank raidz1 /dev/sda /dev/sdb
sudo zfs set compression=zstd tank
sudo zfs create tank/media

Установите Jellyfin:

wget -O - https://repo.jellyfin.org/jellyfin_team.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/jellyfin.gpg
echo "deb [arch=$( dpkg --print-architecture ) signed-by=/usr/share/keyrings/jellyfin.gpg] https://repo.jellyfin.org/$( awk -F'=' '/^ID=/{ print $NF }' /etc/os-release ) $( awk -F'=' '/^VERSION_CODENAME=/{ print $NF }' /etc/os-release ) main" | sudo tee /etc/apt/sources.list.d/jellyfin.list
sudo apt update && sudo apt install jellyfin

Настройте аппаратное ускорение для транскода (H.264):

sudo usermod -a -G render jellyfin
# В веб-интерфейсе: Dashboard → Playback → VaAPI → /dev/dri/renderD128

Производительность:

Direct play (H.264 1080p): до 8 одновременных потоков.
Транскод (1080p→720p): 1 поток (ограничено CPU Pi 5).
Потребление: ~8 Вт в idle, ~12 Вт при воспроизведении.

⚠️ Не пытайтесь транскодировать 4K на Pi — недостаточно мощности GPU.

4. Управление медиатекой

Хорошая медиатека — это не «фильм01.mkv», а структура, которую понимает и человек, и машина.

4.1. Требования к именованию файлов

Для автоматического сопоставления:

Фильмы: Название (Год)/Название (Год).mkv
Пример: Интерстеллар (2014)/Интерстеллар (2014).mkv
Сериалы: Название/Сезон 01/Название - S01E01 - Название эпизода.mkv
Пример: Шерлок/Сезон 01/Шерлок - S01E01 - Исследование в розовых тонах.mkv

📂 Почему не «S01E01.mp4»?
— Нет года → путаница с ремейками (Остаться в живых (2004) vs Остаться в живых (2023)).
— Нет названия эпизода → невозможно понять содержание без открытия.

4.2. Файлы с метаданными рядом

.nfo — XML-файлы для Kodi/Plex (заполняются вручную или через TinyMediaManager).
poster.jpg, fanart.jpg — обложки (1000×1500, 1920×1080).
folder.jpg — обложка альбома для музыки.

Структура альбома:

Pink Floyd/
├── The Dark Side of the Moon (1973)/
│   ├── 01 - Speak to Me.flac
│   ├── 02 - Breathe.flac
│   ├── cover.jpg
│   └── album.nfo

4.3. Инструменты управления

Инструмент	Назначение
FileBot	Автоматическое переименование по TheMovieDB/TheTVDB
TinyMediaManager	GUI для создания `.nfo`, загрузки обложек, управления коллекцией
Beets	Для музыки: исправление тегов, импорт из Discogs, нормализация громкости
MediaElch	Аналог TinyMediaManager, open-source

Пример команды FileBot:

filebot -rename "/downloads" --db TheMovieDB --format "{n} ({y})/{n} ({y})"

5. Резервное копирование и безопасность

5.1. Стратегия 3-2-1

3 копии данных (оригинал + 2 резервных),
2 разных носителя (HDD + облако),
1 копия вне дома (облако или внешний диск в сейфе).

5.2. Шифрование

LUKS (Linux) — шифрование диска целиком.

sudo cryptsetup luksFormat /dev/sdc1
sudo cryptsetup open /dev/sdc1 vault
sudo mkfs.ext4 /dev/mapper/vault

rclone crypt — шифрование на уровне файлов для облака:

rclone config
# создаём remote "gdrive_crypt" как crypt поверх "gdrive"
rclone copy /media gdrive_crypt:backup --transfers=8

5.3. Восстановление после сбоя

ZFS: zpool status → zpool scrub tank → zfs rollback tank@media@snap-20241110.
Btrfs: btrfs scrub start /mnt → btrfs restore /dev/sda1 /recovery.
ext4: fsck -y /dev/sda1 (только если отмонтировано).

6. Юридические аспекты

6.1. Риппинг дисков

Россия: часть 4 ГК РФ, ст. 1273 — свободное воспроизведение в личных целях разрешено, включая риппинг.
ЕС/США: DMCA (Digital Millennium Copyright Act) — обход DRM запрещён, даже для бэкапа.

📜 Практически:
— Риппинг DVD без CSS-обхода — невозможно.
— Использование libdvdcss — легально в РФ, нелегально в США.

6.2. Распространение медиатеки

Внутри семьи (до 5 устройств) — обычно разрешено ToS Plex/Jellyfin.
Публичный доступ (открытый сервер в интернете) — нарушение авторских прав, даже без монетизации.

6.3. Лицензии кодеков

H.264: бесплатен для воспроизведения, но энкодирование в коммерческих продуктах требует лицензии от MPEG LA.
HEVC: сложная система патентов (Via Licensing, MPEG LA) → многие open-source проекты избегают.
AV1: полностью royalty-free → рекомендуется для архивов.

Часть 5. Профессиональные инструменты, веб-медиа и аудиопроизводство

1. Архитектура видеоредакторов

Видеоредактор — не «линейка с клипами». Это мультислойная система обработки временных данных, где каждая операция — узел в графе зависимостей.

1.1. Типы редакторов по архитектуре

Тип	Примеры	Архитектура	Для кого
Linear (только монтаж)	iMovie, Shotcut	Видео → Timeline → Render	Новички, быстрый монтаж
Node-based (постобработка)	DaVinci Resolve (Fusion), Nuke	Граф узлов: MediaIn → Transform → Color → MediaOut	VFX, цветокоррекция
Non-linear + Timeline	Premiere Pro, Final Cut Pro	Timeline + Effects → Real-time Engine → Proxy Workflow	Профессионалы

1.2. Как работает DaVinci Resolve (как типовой профессиональный стек)

DaVinci — не один продукт, а четыре интегрированных среды в одном приложении:

Media Pool — индексация и управление медиа (аналог Jellyfin, но для проектов).
Cut Page — упрощённый монтаж (для YouTube, коротких видео).
Edit Page — полный нелинейный монтаж (multi-cam, nested sequences).
Fusion Page — нодовый композитинг (2D/3D, particle systems).
Color Page — цветокоррекция на GPU (10-bit+ pipeline, LUTs, qualifiers).
Fairlight Page — DAW-уровень для звука (ADR, Foley, surround mixing).
Deliver Page — рендер с профилями (YouTube, Vimeo, ProRes, IMF).

🔧 Ключевая технология: Smart Cache & Proxy Workflow
— Оригиналы (RAW, 8K) → автоматически создаются прокси (H.264 1080p) для монтажа.
— Все эффекты применяются к прокси в реальном времени.
— При рендере — пересчёт на оригиналах без перезагрузки проекта.

1.3. Открытые альтернативы

Функция	Коммерческий инструмент	Open-source аналог
Монтаж	Premiere Pro	Kdenlive, OpenShot, Shotcut
Цветокоррекция	DaVinci	Olive Video Editor (в разработке), Flowblade + LUTs
VFX	After Effects	Natron (нодовый), Blender (Video Sequence Editor + Compositor)
Звук	Audition	Ardour, Reaper (бесплатно для некоммерческого), Audacity
Прокси-генерация	Resolve Auto Proxy	FFmpeg + Bash-скрипт

Пример автоматической генерации прокси для проекта:

#!/bin/bash
# proxy_gen.sh
SRC_DIR="/media/originals"
PROXY_DIR="/media/proxy"
mkdir -p "$PROXY_DIR"

for f in "$SRC_DIR"/*.mkv; do
  base=$(basename "$f" .mkv)
  ffmpeg -i "$f" \
         -vf "scale=1280:720,fps=30" \
         -c:v h264_nvenc -preset p3 -cq 23 \
         -c:a aac -b:a 128k \
         "$PROXY_DIR/${base}_proxy.mp4"
done

Запуск: nohup ./proxy_gen.sh > proxy.log 2>&1 & — фоновый процесс с логированием.

2. Медиа в вебе: как `<video>` стал полноценной платформой

HTML5 <video> — лишь вершина айсберга. Современный веб-медиастек включает:

2.1. API-стек для медиа в браузере

Уровень	API	Возможности
Воспроизведение	HTMLMediaElement (`<video>`)	Базовый контроль: play/pause, volume, currentTime
Динамическая загрузка	Media Source Extensions (MSE)	Построение потока из сегментов в JS (HLS/DASH в браузере без плагинов)
Декодирование/кодирование	WebCodecs	Прямой доступ к кодекам: `VideoDecoder`, `AudioEncoder`
Захват	MediaDevices	`getUserMedia()` (камера/микрофон), `getDisplayMedia()` (экран)
Вывод	Web Audio API, WebGL	Обработка звука в real-time, рендер видео в `<canvas>`

2.2. Как работает MSE (на примере hls.js)

Браузер загружает playlist.m3u8.
JS-библиотека (hls.js) парсит его, запрашивает сегменты.
MediaSource создаёт SourceBuffer.
Сегменты (.ts или .mp4) передаются в sourceBuffer.appendBuffer().
Браузер декодирует и синхронизирует — без участия JS в декодировании.

📊 Почему MSE важен:
— Позволяет реализовать кастомный DRM (например, для корпоративного обучения).
— Поддержка форматов, не встроенных в браузер (например, MKV через webm-wasm).

2.3. WebCodecs: прорыв 2021 года

Раньше: чтобы обработать кадр — video → canvas → getImageData() → обработка → putImageData() → latency `>100 мс.

С WebCodecs:

const decoder = new VideoDecoder({
  output: (frame) => {
    // frame — GPU-текстура (GPUTexture), не CPU-массив
    gpuDevice.queue.copyImageBitmapToTexture(
      { imageBitmap: frame },
      { texture: outputTexture },
      [frame.displayWidth, frame.displayHeight]
    );
    frame.close(); // освобождение ресурсов
  },
  error: (e) => console.error(e)
});
decoder.configure({ codec: 'vp09.00.10.08' });

// Передаём chunk напрямую из fetch
fetch('video.ivf')
  .then(r => r.body.getReader())
  .then(processChunks);

Применения:

Видеоэффекты в реальном времени (Zoom-фильтры),
Транскодирование в браузере (например, WebM → MP4 для загрузки),
Анализ видео (обнаружение лиц через TensorFlow.js + WebCodecs).

⚠️ Поддержка: Chrome 94+, Edge 94+, Firefox 107+ (2023). Safari — частично.

3. Аудиопроизводство

3.1. Цепочка аудиопроизводства

[Источник] → [Микрофон] → [Аудиоинтерфейс]  
     ↓  
[DAW (Digital Audio Workstation)]  
├── Запись (tracks)  
├── Редактирование (cut, fade, comping)  
├── Обработка (EQ, compression, reverb)  
├── Сведение (panning, automation)  
└── Мастеринг (limiting, dithering, loudness normalization)  
     ↓  
[Финальный файл: WAV 24-bit/48kHz → MP3 320kbps]

3.2. DAW: как устроены внутри

Таймлайн — не пиксели, а сэмплы (например, 48 000 сэмплов = 1 сек при 48 кГц).
Плагины — загружаемые модули, соответствующие стандарту:
- VST2/VST3 (Steinberg) — Windows/macOS,
- AU (Audio Units) — только macOS,
- LV2 — Linux (на базе RDF/OWL).

🧩 Архитектура VST3:

Плагин — DLL/dylib, экспортирует GetPluginFactory().

Хост (DAW) вызывает IPluginFactory::createInstance().

Передача аудио — через IAudioProcessor::process() с указателями на буферы.

GUI — через IPlugView, отдельный процесс (для защиты от крашей).

3.3. Открытый стек для аудиопроизводства

Компонент	Инструмент	Замечания
DAW	Ardour (Linux/macOS/Windows)	Поддержка VST2/3, LV2, MIDI, 256 треков
	Reaper	Бесплатно для некоммерческого, скрипты на EEL/Python
	LMMS	Для электронной музыки (паттерн-ориентированный)
Синтезаторы	ZynAddSubFX, Helm	Open-source, multi-engine (FM, subtractive)
Эффекты	Calf Studio Gear, LSP Plugins	LV2/VST3, высокоточные алгоритмы
Мастеринг	LoudMax (limiter), EBU R128 (нормализация)	Соответствие стандартам (Spotify: -14 LUFS)

3.4. Практика: автоматический мастеринг через CLI

Цель: привести трек к стандарту Spotify (-14 LUFS, true peak ≤ -1 дБTP).

Инструменты: ffmpeg, rubberband-cli, sox, ebur128.

Скрипт master.sh:

#!/bin/bash
INPUT="$1"
OUTPUT="${INPUT%.*}_mastered.mp3"

# 1. Нормализация по громкости (EBU R128)
ffmpeg -i "$INPUT" -af "loudnorm=I=-14:LRA=7:TP=-1.5" -y /tmp/normalized.wav

# 2. Ограничение пиков (limiter)
sox /tmp/normalized.wav /tmp/loud.wav gain -n -3

# 3. Конвертация в MP3 с VBR
ffmpeg -i /tmp/loud.wav -codec:a libmp3lame -qscale:a 0 "$OUTPUT"

# 4. Проверка
echo "Проверка громкости:"
ffmpeg -i "$OUTPUT" -af ebur128=peak=true -f null -
rm /tmp/normalized.wav /tmp/loud.wav

Запуск: ./master.sh track.wav
Результат: track_mastered.mp3, соответствующий рекомендациям стриминговых сервисов.

4. История медиаформатов: эволюция под давлением

4.1. Почему одни форматы выжили, а другие — нет

Формат	Причина успеха	Причина провала
MP3	Простота, поддержка в плеерах (1998–2010)	Патенты, уступает AAC/Opus
DivX	Первый H.263+ в AVI, «DVD на CD»	Закрытый, патентные войны
RealMedia	Низкий битрейт для dial-up	Проприетарный, DRM, низкое качество
Flash Video (FLV)	Интеграция с ActionScript	Отсутствие поддержки мобильных, security issues
WebM	Открытый, поддержка Google/YouTube	Нет MP3, слабая поддержка в Apple-экосистеме

📈 Ключевой фактор выживания: поддержка в браузерах без плагинов.
— 2010: HTML5 <video> поддерживает Ogg Theora → но Google купил On2 и запустил VP8 (WebM).
— 2013: Apple отказалась от Ogg → WebM не стал универсальным.
— 2016: все браузеры добавили VP9 → WebM получил второе дыхание.

4.2. Будущее: AV2, VVC и нейрокодеки

AV2 (AOMedia Video 2) — преемник AV1, ожидается в 2025–2026. Цель: +30% эффективности к AV1 при той же сложности.
VVC (H.266) — уже стандартизирован, но сложность кодирования ×10 к HEVC → пока только для архивов.
Neural Codecs (Google Lyra, Meta EnCodec):
— Кодирование речи при 3 кбит/с с качеством Opus 32 кбит/с,
— Но требует ML-ускорителя (NPU), несовместимы с legacy.

🔮 Прогноз: к 2030 г. доминировать будут:
— AV1/AV2 для веба и стриминга,
— VVC для UHD Blu-ray и вещания,
— Neural codecs — для VoIP и low-bandwidth регионов.

5. Практикум: сборка медиастека для IT-специалиста

5.1. Сценарий: автоматизированная обработка загруженных видео

Цель:
— Принимать .mkv из торрент-клиента,
— Конвертировать в совместимый MP4,
— Добавлять метаданные,
— Перемещать в медиатеку.

Стек:

watchdog (Python) — мониторинг папки,
FFmpeg — обработка,
FileBot — метаданные,
Jellyfin API — обновление библиотеки.

Скрипт auto_process.py:

from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
import subprocess, time, requests

class MediaHandler(FileSystemEventHandler):
    def on_created(self, event):
        if event.src_path.endswith('.mkv'):
            self.process(event.src_path)

    def process(self, path):
        # 1. Конвертация
        output = path.replace('.mkv', '_web.mp4')
        subprocess.run([
            'ffmpeg', '-i', path,
            '-c:v', 'libx264', '-profile:v', 'baseline',
            '-c:a', 'aac', '-b:a', '128k',
            '-movflags', '+faststart', output
        ])
        
        # 2. Метаданные
        subprocess.run([
            'filebot', '-rename', output,
            '--db', 'TheMovieDB',
            '--format', '{n} ({y})/{n} ({y})'
        ])
        
        # 3. Уведомление Jellyfin
        requests.post('http://jellyfin:8096/Library/Refresh',
                      headers={'X-Emby-Token': 'YOUR_API_KEY'})

observer = Observer()
observer.schedule(MediaHandler(), path="/downloads", recursive=False)
observer.start()
try:
    while True: time.sleep(1)
except KeyboardInterrupt:
    observer.stop()
observer.join()

Запуск: python3 auto_process.py &

5.2. Сценарий: стриминг экрана в локальную сеть без задержек

Цель: транслировать экран ПК на телевизор с latency <300 мс.

Стек:

OBS Studio (захват экрана),
SRT (надёжная передача),
mpv (воспроизведение на Raspberry Pi).

На ПК (OBS):

Настройки → Вывод → Дополнительно
Тип вывода: Пользовательский
URL: srt://192.168.1.100:1234?mode=caller&latency=200
Кодек: H.264, 1080p30, битрейт 8 Мбит/с.

На Raspberry Pi:

mpv --no-terminal --profile=low-latency srt://:1234?mode=listener

Профиль low-latency в mpv.conf:

hwdec=vaapi
video-sync=display-resample
interpolation=yes
tscale=oversample

Результат: latency ~220 мс, устойчиво к кратковременным потерям пакетов.

Медиа​

1. Медиа как тип данных и как предмет обработки​

2. Классификация медиасофта​

2.1. Локальные (оффлайн) медиаплееры​

2.2. Облачные стриминг-платформы (streaming services)​

3. Архитектура локального медиаплеера​

3.1. Стадия 1: Загрузка и парсинг контейнера​

3.2. Стадия 2: Демультиплексирование и декодирование​

3.3. Стадия 3: Постобработка и рендеринг​

3.4. Стадия 4: Интерфейс и управление​

4. Как получить и использовать локальный медиаплеер​

4.1. Установка​

4.2. Запуск и базовое использование​

4.3. Работа с «проблемными» файлами​

5. Платформенная специфика​

6. Безопасность и этика использования медиасофта​

Часть 2. Форматы, кодеки и структура медиаданных​

1. Контейнер — не «упаковка», а оркестровщик​

1.1. Почему контейнеры необходимы?​

1.2. Сравнение популярных контейнеров​

2. Кодеки​

2.1. Аудиокодеки​

Принципы lossy-аудиокодеков:​

2.2. Видеокодеки​

Эволюция видеокодеков:​

3. Метаданные: невидимый слой информации​

3.1. Уровень контейнера (global metadata)​

3.2. Уровень потока (stream-level metadata)​

3.3. Уровень прикладной семантики (user-facing metadata)​

4. Потоковое вещание​

4.1. HTTP Live Streaming (HLS) — Apple, но де-факто стандарт​

4.2. MPEG-DASH (Dynamic Adaptive Streaming over HTTP)​

4.3. RTMP, SRT, WebRTC — для интерактивного стриминга​

5. Почему «купленный фильм» нельзя сохранить​

6. Практическое руководство: как создать медиафайл​

Инструменты:​

Пример: конвертация в совместимый MP4​

Часть 3. Аппаратное ускорение, цветовые модели и аудиоподсистемы​

1. Аппаратное ускорение​

1.1. Типы аппаратных декодеров/энкодеров​

1.2. Как плеер использует ускорение​

1.3. Проверка и включение ускорения​

2. Цвет в цифровом видео​

2.1. Цветовые пространства (gamut)​

2.2. Функции передачи (transfer functions)​

2.3. Сэмплирование цвета (chroma subsampling)​

2.4. HDR: не «ярче», а «правильнее»​

3. Аудиоподсистемы ОС​

3.1. Путь аудиосигнала в ОС​

3.2. Сравнение аудиосерверов​

3.3. Эквалайзеры​

3.4. 3D-звук: от стерео до пространственного​

4. Тестирование и диагностика​

4.1. Видео: проверка синхронизации и цвета​

4.2. Аудио: измерение latency и искажений​

4.3. Инструменты​

5. Исторический контекст​

Часть 4. Медиасерверы, стриминг и домашняя медиаинфраструктура​

1. Что такое медиасервер? Не просто «папка с фильмами»​

1.1. Три поколения медиасерверов​

1.2. Архитектура Jellyfin (как типового open-source сервера)​

2. Протоколы локального стриминга​

2.1. UPnP/DLNA — стандарт 2000-х, но всё ещё жив​

2.2. Chromecast / Google Cast​

2.3. AirPlay (Apple)​

3. Домашняя медиаинфраструктура​

3.1. Выбор носителя: HDD vs SSD vs NVMe​

3.2. Файловые системы для медиа​

3.3. Сборка медиасервера на Raspberry Pi 5 (практический гайд)​

4. Управление медиатекой​

4.1. Требования к именованию файлов​

4.2. Файлы с метаданными рядом​

4.3. Инструменты управления​

5. Резервное копирование и безопасность​

5.1. Стратегия 3-2-1​

5.2. Шифрование​

5.3. Восстановление после сбоя​

6. Юридические аспекты​

6.1. Риппинг дисков​

6.2. Распространение медиатеки​

Медиа

1. Медиа как тип данных и как предмет обработки

2. Классификация медиасофта

2.1. Локальные (оффлайн) медиаплееры

2.2. Облачные стриминг-платформы (streaming services)

3. Архитектура локального медиаплеера

3.1. Стадия 1: Загрузка и парсинг контейнера

3.2. Стадия 2: Демультиплексирование и декодирование

3.3. Стадия 3: Постобработка и рендеринг

3.4. Стадия 4: Интерфейс и управление

4. Как получить и использовать локальный медиаплеер

4.1. Установка

4.2. Запуск и базовое использование

4.3. Работа с «проблемными» файлами

5. Платформенная специфика

6. Безопасность и этика использования медиасофта

Часть 2. Форматы, кодеки и структура медиаданных

1. Контейнер — не «упаковка», а оркестровщик

1.1. Почему контейнеры необходимы?

1.2. Сравнение популярных контейнеров

2. Кодеки

2.1. Аудиокодеки

Принципы lossy-аудиокодеков:

2.2. Видеокодеки

Эволюция видеокодеков:

3. Метаданные: невидимый слой информации

3.1. Уровень контейнера (global metadata)

3.2. Уровень потока (stream-level metadata)

3.3. Уровень прикладной семантики (user-facing metadata)

4. Потоковое вещание

4.1. HTTP Live Streaming (HLS) — Apple, но де-факто стандарт

4.2. MPEG-DASH (Dynamic Adaptive Streaming over HTTP)

4.3. RTMP, SRT, WebRTC — для интерактивного стриминга

5. Почему «купленный фильм» нельзя сохранить

6. Практическое руководство: как создать медиафайл

Инструменты:

Пример: конвертация в совместимый MP4

Часть 3. Аппаратное ускорение, цветовые модели и аудиоподсистемы

1. Аппаратное ускорение

1.1. Типы аппаратных декодеров/энкодеров

1.2. Как плеер использует ускорение

1.3. Проверка и включение ускорения

2. Цвет в цифровом видео

2.1. Цветовые пространства (gamut)

2.2. Функции передачи (transfer functions)

2.3. Сэмплирование цвета (chroma subsampling)

2.4. HDR: не «ярче», а «правильнее»

3. Аудиоподсистемы ОС

3.1. Путь аудиосигнала в ОС

3.2. Сравнение аудиосерверов

3.3. Эквалайзеры

3.4. 3D-звук: от стерео до пространственного

4. Тестирование и диагностика

4.1. Видео: проверка синхронизации и цвета

4.2. Аудио: измерение latency и искажений

4.3. Инструменты

5. Исторический контекст

Часть 4. Медиасерверы, стриминг и домашняя медиаинфраструктура

1. Что такое медиасервер? Не просто «папка с фильмами»

1.1. Три поколения медиасерверов

1.2. Архитектура Jellyfin (как типового open-source сервера)

2. Протоколы локального стриминга

2.1. UPnP/DLNA — стандарт 2000-х, но всё ещё жив

2.2. Chromecast / Google Cast

2.3. AirPlay (Apple)

3. Домашняя медиаинфраструктура

3.1. Выбор носителя: HDD vs SSD vs NVMe

3.2. Файловые системы для медиа

3.3. Сборка медиасервера на Raspberry Pi 5 (практический гайд)

4. Управление медиатекой

4.1. Требования к именованию файлов

4.2. Файлы с метаданными рядом

4.3. Инструменты управления

5. Резервное копирование и безопасность

5.1. Стратегия 3-2-1

5.2. Шифрование

5.3. Восстановление после сбоя

6. Юридические аспекты

6.1. Риппинг дисков

6.2. Распространение медиатеки